With the emergence of new technologies for mobile telephony, packet-based communication solutions using IP (Internet Protocol) have been developed to support the usage of multimedia services, while different mobile and fixed user terminals with new functionalities for multimedia communication are emerging on the market. Services are also constantly being developed for terminal users to increase the field of usage and enhance the experience when generally consuming communication services.
An IMS (IP Multimedia Subsystem) network can be used for enabling multimedia services and other communication services by initiating and controlling sessions for user terminals connected to various different access networks. The sessions are handled by specific session control nodes in the IMS network, including those referred to as CSCF (Call Session Control Function) nodes.
The signalling protocol called “SIP” (Session Initiation Protocol) is used for multimedia sessions in IMS networks and other communication services networks. IMS is mentioned in this description for illustrative purposes, without limiting the invention to IMS networks exclusively. A user and his/her communication terminal is often generally referred to as a “client”, which term will be used in this description.
FIG. 1 illustrates a conventional communication scenario involving an IMS network 100 serving a client A using a mobile terminal connected to a mobile access network 102. The IMS network 100 comprises various session control nodes, including P-CSCF (Proxy CSCF) 104 providing a point of contact for clients in network 102, S-CSCF (Serving CSCF) 106 controlling various sessions for client A, and I-CSCF 108 (Interrogating CSCF) providing an interface towards other IMS networks (not shown) and which also queries a subscriber database node HSS (Home Subscriber Server) 110 for client related information during client registration and termination. The HSS database 110 thus stores subscriber and authentication data which can be retrieved by other nodes for serving and handling different clients.
The IMS network 100 also comprises a plurality of application servers 112 configured to provide different communication services when invoked to meet service requests for clients. Each application server 112 may be configured to provide a specific service or a particular set of services. The application servers 112 are linked to the session control signalling over an interface to the S-CSCF node 106 called the ISC (IMS Service Control) interface.
The application servers 112 are further configured to execute their services according to certain predefined criteria and corresponding instructions referred to as iFC (initial Filter Criteria) which are maintained in the HSS node 110 for clients. Among other things, the iFC contains criteria for when the iFC is to be applied for an incoming service or registration request, and also instructions for how the S-CSCF node 106 should act when those criteria are fulfilled, i.e. when the iFC criteria matches the request and thereby triggers. When applied, the iFC thus identifies or points to a particular application server to be used for executing one or more specific services for the requesting client. The S-CSCF node 106 then sends the request to the identified application server with that server's name added to a route header of the request.
One or more iFC:s valid for different services can be included in a profile defined for a client. When a client not previously registered either makes a new registration request, or a request bound for the client is received for a particular service, the S-CSCF node 106 downloads the iFC:s associated to the client from HSS 110 and invokes an appropriate application server 112 accordingly to serve the client, e.g. to execute a requested service. Once downloaded from the HSS, the iFC:s are stored or cached in the S-CSCF node 106 for future use whenever other originating or terminating requests are received for the client.
In order to provide differentiated communication services to clients, it is necessary to store and maintain user specific service data in multiple nodes in the IMS network, such as various application servers and the above-described HSS node, as well as other nodes such as and DNS (Domain Name Server)/ENUM, and so forth. This process is referred to as “provisioning” and typically involves establishment of iFC data, service authorisation data which specifies what service(s) a client is authorised to use, and service configuration data which specifies how the service(s) should be executed for the client. The term “service data” will be used for short in this description to represent the service authorisation and configuration data above.
The service data should thus be provisioned in corresponding application servers to enable delivery of services adapted to individual clients, and the provisioning activities are performed by means of a provisioning system, as illustrated in FIG. 2. Furthermore, user specific service data in the HSS and application servers must be coordinated and consistent, for which the provisioning system 200 is responsible. Thus, provisioning system 200 has a so-called “northbound” interface towards an administrator 202 which could be a person and/or a network operator's Customer Administration System or the like, for adding, modifying or deleting user specific service data, e.g. in an IMS network.
The provisioning system 200 in FIG. 2 comprises a schematically shown provisioning logic 200a which basically processes input data from administrator 202 and creates provisioning data that is supplied over dedicated “southbound” interfaces to different nodes in the IMS network, in this case including an application server (AS) 204, an HSS node 206 and an ENUM/DNS node 208. Hence, the provisioning system 200 must handle several different interfaces and is responsible for keeping the user specific service data consistent and up-to-date in all these nodes.
An application server can maintain such service data for users either in a local storage connected to the server or in a central storage accessible for multiple application servers, e.g. the subscriber data node HSS. The user specific data stored in HSS is sometimes referred to as transparent data or “BLOB” which is maintained and used by the application server, and non-transparent data which more generally relates to non application server specific data such as subscriber identities and other network related user data. Both transparent and non-transparent user data in HSS can be accessed by the application server over the Sh interface.
The provisioning logic 200a with its multiple interfaces towards different nodes, is typically quite complex and costly to develop and maintain. It is possible to reduce the provisioning complexity by using “default” service data and policies preconfigured locally in the application servers, instead of provisioning the user specific service data. However, the service data will then be the same for all users and differentiated services in terms of service authorisation and configuration cannot be accomplished for different clients. It is thus a problem of complexity in the provisioning logic and also capacity in the provisioning system, while differentiated communication services adapted to specific clients are desirable.